Day 03｜我先把 Inspector 關掉，自己走一次活動網站

專案跑起來後，我刻意先不開 Inspector，也不叫 Agent 幫忙。我從活動列表開始，
親手找活動、看詳情、收藏，再一路走到報名與取消。這個順序很重要：如果我連人類
原本怎麼完成任務都說不清楚，就很容易把幾顆寫著 Tool 名稱的按鈕誤當成產品能力。

我選活動網站也不是因為畫面好做，而是它原本就有清楚的任務：找活動、確認資訊、
收藏、報名，以及在反悔時取消。同一個網站裡，剛好同時存在唯讀、可復原寫入與
需要人類確認的高影響操作。

這些操作的風險不同。搜尋是唯讀；收藏會改變 session 狀態，但可以復原；報名與
取消會影響使用者權益，應該讓人看完內容再確認。剛好可以用同一個網站討論能力、
結果與停點，不需要再加付款或後台。

今天固定使用同一筆公開活動：

固定資料不是為了把 Demo 寫死，而是讓搜尋結果、route、測試斷言與 Inspector trace
能互相核對。如果文章用「前端高峰會」，程式卻回傳「WebMCP 入門工作坊」，即使
兩邊各自成功，也不能拼成同一條證據鏈。

圖 1：先固定人類如何完成任務，後面才能判斷 Agent 應該協助到哪裡。

我先用表單找一場符合條件的活動

開啟 http://127.0.0.1:5173/events，設定：

• 地點：台北
• 費用：免費
• 程度：入門

按下「搜尋活動」後，結果只留下 evt-webmcp-intro，也就是「WebMCP 入門工作坊」。
卡片保留日期、摘要與 opaque ID，並提供「查看詳情」。

圖 2：人類使用可見表單完成搜尋；右下方 audit trail 記錄的是 human 操作。

這個流程在瀏覽器不支援 document.modelContext 時仍能使用。這點很重要：
WebMCP 應是 progressive enhancement，不該把原本正常的搜尋表單變成 Agent
專用入口。

進到詳情後，我才知道「目前活動」是誰

按「查看詳情」後，route 變成：

/events/evt-webmcp-intro

詳情頁列出 2027 年 1 月 23 日 10:00–12:00、台北前端共學空間與剩餘 8 名。
使用者可以直接收藏，也可以前往報名。收藏成功後，按鈕與狀態訊息會同步更新，
再次收藏則回傳冪等結果，不會偷偷多建一筆。

圖 3：詳情 route 提供完整活動上下文；收藏是低風險寫入，報名則進入另一個流程。

route 在這裡不只是網址。它回答「目前是哪一場活動」，讓畫面、API 與後續 Tool
共用 evt-webmcp-intro，不用拿「current」「active」這類猜測字串代替活動 ID。

收藏則讓我們觀察另一種狀態。它會寫入目前 session，畫面立即顯示已收藏，也提供
Undo。重新整理後狀態仍由 server 回傳，不靠按鈕文字自說自話。這比純前端布林值
更接近真實產品，但仍不等於永久帳號收藏。

填好報名資料，我先停在最後一按之前

從詳情頁前往：

/events/evt-webmcp-intro/register

報名頁顯示活動、姓名與 Email。表單可以先帶入資料，但按鈕明確寫著
「我確認並送出報名」。送出後，/registrations 才會出現有效報名。

圖 4：填好欄位不等於已報名；正式 POST 發生在人類確認之後。

「我的報名」頁也沒有直接放一顆無提示的刪除按鈕。使用者先選「準備取消」，
查看活動與取消後果，最後決定保留或確認取消。

取消影響既有報名，因此先顯示後果，再讓人做最後決定。這一段先用人類 UI 建立
基線；Day 21 再把 Agent 準備取消、重複呼叫與 session 失效放在同一條流程檢查。

這三條流程的 browser baseline 使用以下測試重播：

npx playwright test `
  tests/browser/events-human.spec.ts `
  tests/browser/saved-event.spec.ts `
  tests/browser/registration.spec.ts `
  tests/browser/cancellation.spec.ts

本次結果為 8 passed。測試涵蓋鍵盤搜尋、無 modelContext fallback、收藏與 Undo、
報名零 POST 準備，以及取消 dialog 的 human confirmation。

這組測試也把「準備」和「送出」分開。報名頁可以先顯示姓名與 Email，但 network
記錄在準備階段必須是零 POST；只有人類按下確認後才能建立一筆報名。取消亦然：
開啟 dialog 不得改變狀態，確認按鈕才送出 mutation。後面設計 prepare Tool 時，
沿用的就是這條已經存在的人類產品邊界。

走完三條流程後，我決定不再擴功能

活動網站已經同時具有資訊讀取、可復原寫入與高影響操作。再加付款、OAuth、
資料庫或管理後台，確實會讓專案看起來更大，卻不會讓 WebMCP 的問題更清楚。

目前 Demo 使用 session 與 server authority 驗證操作，但它不是正式會員系統。
把 non-goals 寫出來，讀者才不會把 session demo 誤認成完整 RBAC。

活動案例還有一個實際優點：每個結果都能回到畫面檢查。搜尋後有卡片，收藏後有
狀態，報名後會出現在「我的報名」。若 Agent 未來真的參與其中，人類不需要另開
一個黑盒子聊天紀錄猜它做了什麼。

手動走完後，搜尋表單、詳情 route、收藏狀態與人類確認都已經有了清楚基線。接著我
會把其中一段交給 Playwright 重播，看看自動化程式究竟依靠哪些畫面線索，才能按到
我剛才按過的同一顆按鈕。